NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c/165

Internet Message Format | 1996-08-06 | 4.4 KB

Path: solon.com!not-for-mail
From: [e-mail] (Tanmoy Bhattacharya)
Newsgroups: comp.lang.c.moderated,comp.std.c
Subject: Re: Is this legal prototype syntax?
Date: 23 Jan 1996 06:34:32 -0600
Organization: Los Alamos National Laboratory
Sender: [e-mail]
Approved: [e-mail]
Message-ID: <4e2kko$[e-mail]>
References: <4dp6l2$[e-mail]> <4dpv3g$[e-mail]>
    <4duuat$[e-mail]> <4e1mna$[e-mail]>
NNTP-Posting-Host: solutions.solon.com

--text follows this line--

Please note crosspost.

In article <4e1mna$[e-mail]> The Amorphous Mass
<[e-mail]> writes:
<snip>
   >     Yes.  *b and b[] are identical in the context of function parameter lists.
   >
   > Actually, the correct answer is _currently_ they are
   > identical. However, there is an intent in the standard (i.e. the
   > standard encourages following this rule) that if two objects are
   > declared arrays instead of pointers (even though they will be adjusted
   > to pointers), they will be distinct objects. Thus, it is better not to
   > say void FTNSUB(int *a, int b[], int c[]) unless b and c will always
   > be distinct. Note that a need never be distinct: an object declared
   > pointer can point anywhere.

     Hmmm.  Could you elaborate?  Does that mean that if I have

My statement is based on the single sentence

6.9.6 The use of two parameters declared with an array type (prior to
adjustment to pointer type) in separate lvalues to designate the same
object is an obsolescent feature.

For comp.std.c { I must admit I do not follow how two parameters can
be declared with an array type in non-separate lvalues, the cross-post
to comp.std.c may result in further illumination. More likely, the
statement means that two _distinct_ parameters, each declared with an
array type, may not be used to form separate lvalues, if the said
lvalues refer to the same object: i.e. if b and c are two parameters
*(b+3) must not be the same object *(c+2) either if both are used. Of
course this interpretation would also demand that for any pointers a,
if *(a+(b-b)) is used, *(a+(c-c)) must not be. This is peculiar to say
the least.

`may' or `may not' in the above para refer to requirements to prevent
obsolescence.
}

     int a[100];
     f(a);
     /* ... */
     void f(int b[]) { /* ... */ } /* assume f has been prototyped */

     that I can't treat b as a pointer to a?  Or, if I have

I do not think the statement applies to this. There are no two
parameters declared with an array type. In any case, what the intent
may be is that the compiler may some day legally make the assumption
that two array parameters are distinct, and hence optimize
accordingly. From my reading of that statement, a parameter
overlapping a global continues to remain a possibility. Whether this
was intended, I cannot say. I can see, vaguely, reasons for allowing
overlaps with global: echoes of noalias resound otherwise.

     int *a = malloc(100 * sizeof(int));
     f(a);
     /* ... */
     void f(int b[]) { /* ... */ }

     that b is treated something like a const pointer to int?  Will this

No. It will continue to be a pointer to int.

   affect people who use int main(int argc, char *argv[]) instead of int
   main(int argc, char **argv[])?  Will the two statements remain equivalent

I hope nobody uses the char **argv[] form :-) Whether the char *argv[]
and char **argv will continue to remain equivalent I cannot say
reading the standard alone, but note that technically the standard
only says that char *argv[] is legal: the legality of char **argv
depends on the equivalence, not the other way round.

   or not?  Or is this just for inter-language purposes, as your FTNSUB
   example implies?

No, it is only to leave room for later standards to make the meaning
clearer.

     Thanks for any enlightenment you can provide.

I am waiting for enlightenment myself ...

Cheers
Tanmoy
--
[e-mail](128.165.23.46) DECNET: BETA::"[e-mail]"(1.218=1242)
Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87545 H:#9,3000,Trinity Drive,NM87544
Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
fax: [phone]   voice: 1 [phone]    [ Home: 1 [phone] ]